POV-Ray : Newsgroups : povray.binaries.images : texture_map problem : Re: texture_map problem Server Time
2 Nov 2024 12:22:04 EDT (-0400)
  Re: texture_map problem  
From: Jörg 'Yadgar' Bleimann
Date: 16 Dec 2010 10:45:37
Message: <4d0a3421@news.povray.org>
High!

On 15.12.2010 22:53, Dre wrote:

> Hey, I live in southern Tasmania!!

In Hobart?

>
> I dont suppose you could tell me where you got the data for the heightfield?

Look here: http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Australia/

These are data tiles from a Shuttle Radar Topography Mission (SRTM) in 
February 2000, covering the entire land surface of the Earth between 

of 3 arcseconds per data point. The name of each file indicates the 
geographical coordinates of the *southwestern*, i. e. left lower corner 
of the tile. So, you just look up the coordinate range of Tasmania in 
your preferred atlas and find the respective tiles.

These tiles are NOT image files, but you can make them visible (and even 
generate nice 3-D views, which export also to VRML) with a Windows 
freeware called "3DEM". You find 3DEM here: 
http://freegeographytools.com/3dem_setup.exe
With 3DEM, you can iron out error pixels (mostly resulting from cloud 
cover) with the "Patch missing data" feature - but this works only for 
error pixels which have no connection to the tile's edges!

To use them with PoV-Ray, you'll have to export the read-in data tile as 
"ASCII terrain matrix". I wrote a POV script which generates a 16-bit 
PNG heightfield from these ASCII files - attached here (ascii2png.pov)!

The ASCII files have the height data as number strings at two-digit 
accuracy (xxxx.xx), each separated by a blank. PoV-Ray needs the blanks 
to be replaced by commas to read the data in properly. If you have 
access to Linux with its powerful UNIX console command line tools, 
you're fine - just type in:

sed 's/ /,/g' original_file destination_file

and within two seconds, almost 1,5 million blanks are replaced by commas!

Unfortunately, I currently do not know of any Windows tool capable of 
doing that job at a comparable speed - common GUI text editors, not to 
mention full-fledged word processors toil for hours! But even if you 
have no Linux on your computer, you can download a "Live CD" image of a 
Debian distribution and burn it - afterwards you'll be able to boot a 
proper Linux installation from the disk! If you face problems to write 
data on your harddisk (because of missing rights), just try a USB stick 
instead, it probably will work!

Note that the size of the data tiles is in fact 1201 by 1201 rather than 
1200 x 1200, so adjacent rows and columns would repeat - if you want to 
join two or more of your generated PNG heightfields, you'll first have 
to remove the easternmost column and southernmost row.

And joining heightfields would be the only way to get rid of the error 
pixels which, with the original tiles, lie at the edges. I also wrote a 
POV script (png2ascii.pov) to re-export joined heightfields to an ASCII 
terrain matrix readable by 3DEM - the software will ask you about the 
size and corner coordinates and then you can smooth out the remaining 
error pixels.

After exporting them back to ASCII (and, of course, once more replacing 
blanks by comma) and finally to PNG, you'll have a faultless heightfield 
of your desired area. Note that the creation of the PNG heightfields 
required quite at lot of memory, as each "pixel" in fact is a small box 
object rendered in an orthographic view without light_source but with 
ambient 1 - to do 1200 x 1200 boxes, you should have at least 1.5 GB of RAM!

As the tiles are square degree tiles, the resulting cartographic 
projection is cylindrical, so that only along the Equator, the 
heightfields give a realistical representation of terrain, while towards 
the poles, the terrain is increasingly stretched in west-east direction.

To get an undistorted landscape, you'll have to finally convert the PNG 
heightfield into a mesh2 which follows Earth's curvature according to 
its geographical coordinates. I also wrote a script to do this 
(mesh2writer), but as you see in the example rendering I attached, some 
artifacts resulting from floating point inaccuracy show up. To avoid 
them, we probably must use Christoph Hormann's IsoCSG include 
(http://www.imagico.de/pov/ic/index.html) which is able to convert a 
mesh2 into an isosurface!

I added two scripts I wrote to do the conversion from PNG to mesh2 - 
mesh2writer.pov which writes the full POV code for the entire mesh (for 
parsing speed reasons, the mesh2 is generated only once and then written 
to harddisk), and png2mesh2.pov which includes the code written by the 
former script and generates the scene from it.

> I'm very interested in recreating the area around my house for starters :)

As the SRTM data tiles mentioned above have an effective resolution of 
about 90 metres per data point, you'll be better off with pixeling 
heightfield from a scanned-in topographic map, perhaps 1:25,000 (which 
can be quite cumbersome work)... but then adjusting it to Earth 
curvature would be somewhat difficult, as those maps are based on 
geodetic (equal distances between points) rather than geographic 
coordinates.

> Then the whole island, that would be sweet!!!

Yes, with Tasmanian Tigers roaming the forests! In fact, I think 
Tasmania a very interesting part of the world, as it is located in the 
"Roaring Forties", mainly when it comes to vegetation and animals, and I 
really would like to visit your island!

See you in Khyberspace!

Yadgar


Post a reply to this message


Attachments:
Download 'us-ascii' (3 KB) Download 'png2mesh2.pov.txt' (3 KB) Download 'ascii2png.pov.txt' (1 KB) Download 'png2ascii.pov.txt' (1 KB) Download '2010-11-20 afghan highlands south of koh-e baba range, take 1 (yadgar).jpg' (42 KB)

Preview of image '2010-11-20 afghan highlands south of koh-e baba range, take 1 (yadgar).jpg'
2010-11-20 afghan highlands south of koh-e baba range, take 1 (yadgar).jpg


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.